<html>
<body>
  <p>DTOs for the booking client facade.</p>
  <p>DTOs are designed in a use case-driven fashion, closely related to the
    service layer interface. They represent a particular section of the domain
    model, which may cross aggregate boundaries. They have no business logic and
    are immutable.</p>
  <p>The reason for using DTOs is mainly to loosen the coupling of the
    application and the user interface. It allows us to build the domain model
    completely without having to conforming to any UI-related conventions or
    requirements, such as JavaBean getter methods or no-args constructors. We
    also avoid exposing functionality that is internal to the domain model to
    the UI layer.</p>
  <p>Furthermore, we have a clear contract for what part of the object graph
    is loaded from the database when the service layer call returns. If domain
    model objects are passed on to the UI layer, it will be necessary to keep
    the database access window (e.g. the Hibernate session) open during the
    entire processing of the view (the Open Session In View pattern), otherwise
    an uninitialized part of the model could accidentally be accessed, causing
    an error. For example, if the UI layer were to receive a Cargo instance,
    that could be navigated to access the Itinerary, iterate over the Legs of
    the itinerary, access the Leg's CarrierMovement and then the
    CarrierMovement's Location and so on. In addition to effectively tying the
    UI layer and the rest of the application to the same JVM, letting the UI
    layer decide when to initialize data may be very inefficient. DTOs are a
    natural way of loading only the relevant data for a particular use case, and
    blocking access to the rest.</p>
  <p>Using DTOs also makes the service layer reusable across different kinds
    of front-ends: web, rich clients, other back-end systems etc. Remember that
    classes that are persisted with Hibernate or similar technologies are
    modified in runtime, so that for example collection-valued fields are
    swapped for customized implementations that allow lazy loading. If these
    persisted domain model classes are to be de-serialized in another JVM, those
    O/R-mapping-specific classes need to be available there as well, which is
    not very elegant.</p>
  <p>A caveat to consider: The usefulness of DTOs may vary with the degree
    of vertical separation in the application. If it's very unlikely that your
    application will use anything other than a web interface, and that it
    otherwise are no problems running the web layer together with the rest of
    the application, you may want to avoid the overhead of maintaining several
    similar sets of classes.</p>
</body>
</html>
